home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20020314-20021006
/
000026_ishikawa@yk.rim.or.jp_Sun Apr 7 14:28:41 EDT 2002.msg
< prev
next >
Wrap
Text File
|
2002-10-06
|
10KB
|
288 lines
Article: 13297 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!newsfeed.rim.or.jp!news.rim.or.jp!not-for-mail
From: Ishikawa <ishikawa@yk.rim.or.jp>
Newsgroups: comp.protocols.kermit.misc
Subject: a bug on GNU/linux: speed reset to unintended value occasionally.
Date: Sun, 07 Apr 2002 16:41:16 +0900
Organization: Ye 'Ol Disorganized NNTPCache groupie
Lines: 265
Message-ID: <3CAFF81C.8039CBF8@yk.rim.or.jp>
NNTP-Posting-Host: pl493.nas911.n-yokohama.nttpc.ne.jp
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-Trace: news.rim.or.jp 1018165279 99035 210.139.38.237 (7 Apr 2002 07:41:19 GMT)
X-Complaints-To: root@rim.or.jp
NNTP-Posting-Date: Sun, 7 Apr 2002 07:41:19 +0000 (UTC)
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: ja, en
Cache-Post-Path: duron!unknown@localhost
X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13297
Hello,
I have been an occasional user of Kermit over
the years. Thank you for making the great package
available. (Occassional may not be quite correct.
Our Cisco router at the office is hooked to a
Solaris box using a serial line and monitored by
a kermit program on solaris. Not that I monitor
cisco from this console all the time.)
Recently I noticed a bug of kermit on GNU/linux.
So I would like to report this and
see if others have seen the same bug.
The problem is that the connection
speed is reset occasionally to an unintended
setting upon return to kermit prompt a la "control-\ C"
sequence.
Usually this transition happens to a slower speed.
(Well, come to think of the speed
may have been set to unintended speed already
when I issue "connect" command. I have no idea if
this was why connections failed when the bug
appeared.)
I first noticed this on RedHat GNU/linux 7.2
that uses linux kernel 2.4.x (x being lower than 10, I think).
The bug was noticed with the Kermit redhat binary/RPM available
>from Columbia university web page.
(Now come to think of it, I *may* have downloaded
a version from somewhere where new kermit RPM package was
made available. But the bug persists with a Columbia-built
binary on Debian GNU/Linux, too. See below.)
Today I rechecked the existence of the bug
on a Debian GNU/Linux (that uses 2.4.17 kernel.
I subustituted the kernel on my own.) and using the
binary from Columbia university. I downloaded the
kermit fresh from the web page.
I could capture a log that shows the bug.
Here is a relevant part of the
log captured using "script" command
on GNU/linux.
I sanitized the log a little bit by
deleting the misspelled command lines, etc..
Since the bug (resetting to an unintended speed)
appears on two different GNU/Linux platforms
I suspect that the bug is very likely to be
in the GNU/linux version of KERMIT, but I will not rule
out the possibility of linux tty driver.
(I recall that solaris v7 kermit had a bug in that
it used the wrong path in the source code about
two years ago. It had something to do with
either using TERMINFO or POSIX style tty handling.
This was fixed with my discovery and input.
Thank you for fixing the bug very quickly back then.
I hope this new bug on GNU/linux can be fixed
in a similar manner.)
REPEAT-BY:
I am not sure if this is truely
reproducibile. I have not checked if
the bug is history-sensitive. It might as well be.
On RedHat GNU/Linux, when I noticed the bug,
usually I tried to set the speed to 38400 or 19200
and tweak the parity setting using "set parity hardware"
to obtain full 8bit data and even parity. (8E1).
While I tweak these settings and find the
communication failure and come back to the prompt
I found that the speed is reset inadvertedly.
(I had thought that resetting parity or
data bytesize may be responsible, but
>from what I see in the following short log,
simply connecting and reverting to the prompt
may reset the speed occasionally under
certain conditions. And the speed may be
reset upon connection if I am not mistaken when
the bug appears.)
Please note in the following log
the connection speed was found to be 1800 upon
exit to kermit prompt near the end.
It had been set to 19200 previously.
So it could have been reset when the connection was made
or when the connection was temporarily suspended
and kermit prompt appeared.
On my experience on RedHat GNU/Linux 7.2,
the speed was often reset to 2400 from 38400/19200.
Something IS wrong in GNU/linux and kermit combination.
ishikawa@duron$ su
Password:
duron:/home/ishikawa# kermit
C-Kermit 8.0.201, 8 Feb 2002, for Linux
Copyright (C) 1985, 2002,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
(/home/ishikawa/) C-Kermit>set line /dev/ttyS0
(/home/ishikawa/) C-Kermit>show
Show what? (Type "show ?" for a list of possiblities.)
(/home/ishikawa/) C-Kermit>show communications
Communications Parameters:
Line: /dev/ttyS0, speed: 9600, mode: local, modem: generic
Parity: none, stop-bits: (default) (8N1)
Duplex: full, flow: rts/cts, handshake: none
Carrier-watch: auto, close-on-disconnect: off
Lockfile: /var/lock/LCK..0
Terminal bytesize: 8, escape character: 28 (^\)
Carrier Detect (CD): Off
Dataset Ready (DSR): Off
Clear To Send (CTS): Off
Ring Indicator (RI): Off
Data Terminal Ready (DTR): On
Request To Send (RTS): On
Type SHOW DIAL to see DIAL-related items.
Type SHOW MODEM to see modem-related items.
(/home/ishikawa/) C-Kermit>set speed 38400
/dev/ttyS0, 38400 bps
(/home/ishikawa/) C-Kermit>set parity hardware
(/home/ishikawa/) C-Kermit>set flow-control none
(/home/ishikawa/) C-Kermit>set parity none
(/home/ishikawa/) C-Kermit>show comm
Communications Parameters:
Line: /dev/ttyS0, speed: 38400, mode: local, modem: generic
Parity: none, stop-bits: (default) (8N1)
Duplex: full, flow: none, handshake: none
Carrier-watch: auto, close-on-disconnect: off
Lockfile: /var/lock/LCK..0
Terminal bytesize: 8, escape character: 28 (^\)
Carrier Detect (CD): Off
Dataset Ready (DSR): Off
Clear To Send (CTS): Off
Ring Indicator (RI): Off
Data Terminal Ready (DTR): On
Request To Send (RTS): On
Type SHOW DIAL to see DIAL-related items.
Type SHOW MODEM to see modem-related items.
(/home/ishikawa/) C-Kermit>conn
Connecting to /dev/ttyS0, speed 38400
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
?Carrier required but not detected.
***********************************
Hint: To CONNECT to a serial device that
is not presenting the Carrier Detect signal,
first tell C-Kermit to:
SET CARRIER-WATCH OFF
***********************************
(/home/ishikawa/) C-Kermit>(/home/ishikawa/) C-Kermit>set carrier-watch
off
(/home/ishikawa/) C-Kermit>conn
Connecting to /dev/ttyS0, speed 38400
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
(Back at duron)
----------------------------------------------------
(*CI comment: The speed was OK by looking at "show comm" output
which was omitted here. *)
(/home/ishikawa/) C-Kermit>set parity hardware
(/home/ishikawa/) C-Kermit>conn
Connecting to /dev/ttyS0, speed 38400
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
(Back at duron)
----------------------------------------------------
(*CI comment: The speed was OK by looking at "show comm" output
which was omitted here. *)
(/home/ishikawa/) C-Kermit>set speed 19200
/dev/ttyS0, 19200 bps
(/home/ishikawa/) C-Kermit>conn
Connecting to /dev/ttyS0, speed 19200
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
(Back at duron)
----------------------------------------------------
(/home/ishikawa/) C-Kermit>show comm
*****************************************************************
Aiiiieeee
(CI comment: Please note the speed here. It is reset to 1800 !!! )
*****************************************************************
Communications Parameters:
Line: /dev/ttyS0, speed: 1800, mode: local, modem: generic <===!!!
HERE
Parity: hardware even, stop-bits: (default) (8E1)
Duplex: full, flow: none, handshake: none
Carrier-watch: off, close-on-disconnect: off
Lockfile: /var/lock/LCK..0
Terminal bytesize: 8, escape character: 28 (^\)
Carrier Detect (CD): Off
Dataset Ready (DSR): Off
Clear To Send (CTS): Off
Ring Indicator (RI): Off
Data Terminal Ready (DTR): On
Request To Send (RTS): On
Type SHOW DIAL to see DIAL-related items.
Type SHOW MODEM to see modem-related items.
(/home/ishikawa/) C-Kermit>echo ? Text to be echoed
(/home/ishikawa/) C-Kermit>echo
(/home/ishikawa/) C-Kermit>quit
Closing /dev/ttyS0...OK
duron:/home/ishikawa# exit
PS:
The above log was recorded when there was no
connection to /dev/ttyS0.
The bug on RedHat 7.2 was noticied when a
digital hardware serial port was directly connected
to a serial port.
As a matter of fact, I checked the speed setting by
"show comm" output after each command of the above sequence,
and I am not entirely sure what triggers the bug.
But the bug is real.
I have been bitten with this many times
in the past several weeks.
My guess is that the change of speed from the prompt and/or
parity setting may trigger the bug, but
maybe others might have seen the
same bug on GNU/Linux and input from other people
might help us in pinpointing the cause of the bug.
PPS: Or maybe certain data structure change
in the linux kernel might have made the
previously correct kermit code no longer valid, etc..